25 lat mijania się z prawdą

Kto nie chciałby zobaczyć, jak tym wystąpieniem niszczę swoją karierę? Minęło 25 lat, co brzmi jak wyrok za ciężką zbrodnię z mrocznych zakątków kodeksu karnego, ale dla mnie to czas podsumowań. Prezentacja, stand-up, coaching? - nazwijcie to jak chcecie. Będzie o naszej branży, biznesie i o nas samych, o "uniwersalnych kłamstwach", które często powtarzane stają się prawdą. To będzie brutalny przewodnik po karierze w IT. Wielu z was zapewne poczuje się urażonych, ale jestem gotów na to poświęcenie. Czy wybór technologii ma znaczenie? Dlaczego większość stanowisk to "bullshit jobs"? Czy greenfieldy naprawdę są takie fajne? Komu potrzebne są estymaty? Co się dzieje, kiedy nie udaje się dowieźć sprintu? Jak feedback stał się rakiem toczącym organizacje? Dlaczego duża część z nas ma wrażenie, że ciągle robi to samo? I jak w tym bajzlu zachować szacunek do siebie, zdrowie psychiczne i dobrze bawić się przez 25 lat? Postaram się odpowiedzieć na te i inne pytania, które sam sobie stawiam od dłuższego czasu. Ci którzy odsieją śmiech przez łzy w tej prezentacji, odnajdą kilka cennych rad jak pokierować swoją karierą.

Wydajność aplikacji Java dla ciekawskich

Celem tego warsztatu jest łagodne wprowadzenie Cię w świat wydajności na platformie JVM. Nie wiesz nic o JMH, JFR, async profiler, dlaczego twój kod musi być wygrzewany? Nigdy nie widziałeś "flamegraph"?

Spokojnie. Tego wszystkiego dowiesz się podczas jednodniowego warsztatu. Skupimy się nie tylko na narzędziach, ale także na procesie i technikach optymalizowania wydajności. Weźmiemy na warsztat jeden z sztandarowych modeli przetwarzania danych, "map reduce". Od prostej jednowątkowej implementacji, po wielowątkowe monstrum oparte o fork-join pool, będziemy poznawać techniki i narzędzia pracy z testami wydajnościowymi ( w skali micro, znanymi także jako "microbenchmark").

Będzie też czas na zapoznanie się z mechanizmami JVM, takimi jak just-in-time compiler, garbage collector czy adaptive locking. Więcej informacji na stronie https://jvmperformance.pl/.

Wymagania

• JDK 20
• Docker
• Maven
• Zaznajomienie się z biznesowymi i technicznymi metodami modularyzacji systemu.
• IDE

Wolni jak ślimaki, pasywni jak rurkowce

Jest rok 2023. Postęp technologiczny, który widzimy robi wrażenie. Mimo to pytanie, które w kuluarach zadaje sobie wiele (większość?) firm wytwarzających oprogramowanie brzmi “Co zrobić by software development był u nas szybszy? Okazuje się, że jako ruch Software Craftsmanship mamy odpowiedź na to pytanie.

W trakcie prezentacji spojrzę na temat szybkości wytwarzania oprogramowania – problemy, przyczyny i rozwiązania z różnych perspektyw. Pokażę kto znajduje się w centrum tego zagadnienia i jak może sprawić by było lepiej 😉

Dyskrecja DevOpsa. Co robimy w ukryciu?

Bezpieczeństwo danych, wdrożenia na produkcję, milionowe biznesy i dostęp tylko w razie potrzeby. Wszystkie aspekty automatyzacji budowania i wdrażania aplikacji w zabezpieczonym środowisku składają się na obraz zadania, które jednocześnie ma dobrze znane prawidłowe rozwiązania i bardzo łatwo zrealizować je źle. A ponieważ konsekwencje zaniedbań mogą spowodować nagłe zmiany w karierze, to warto o nich pomyśleć wcześniej. Zróbmy to teraz.

Beyond Clean Code: Ethernal architectural practises

In this talk we will cover: thinking in terms of abstractions, placing the right language in the right places, fighting with cognitive load and biases, what kinds of coupling can we see and which one is the worst, how to overcome the fear of having many small classes, hot to explain cohesion to a junior developer and more. Those evergreen rules can help you become more efficient and persuasive at work.

(Nie)trudna sztuka modelowania agregatów

Agregaty to chyba natrudniejszy element konstrukcyjny taktycznego Domain-Driven Design. Czy naprawdę chodzi tylko (lub aż) o dobrze skrojone programowanie obiektowe?

Dobrze zaprojektowany agregat potrafi wyeliminować potrzebę dokupowania chmury dla naszych czterdziestu mikroserwisów. Źle zaprojektowany agregat potrafi sprawić, że używanie systemu jest koszmarem.

W tym praktycznym warsztacie przejdziemy przez typowe przypadki modelowania i implementacji agregatów. Tak, typowe, bo... nasze projekty mocno się nie różnią. Zahaczymy też o archetypy.

Wymagania

• Laptop
• GIT
• Większość warsztatu odbędzie się na platformie miro.com, więc dobrze się z nią zapoznać (zajmuje sie jakieś 2 minuty)
• Dodatkowo warto mieć zainstalowane ulubione IDE, ulubiony język oraz klienta git (bo może pojawi się nasz wspólny kod)
• będziemy pracować w grupach (2-4 osobowych, w zależności od liczby osób)

Best practices in practice: things that work for me so well I cannot believe you are not using them

There’s a lot of “best practices” around, but after 20 years of work I’ve found a set that really helps get my systems done well. I’d like to share those tools and methods and why they work in my context. While they are not a novelty (some of them have years of history), I see even experienced developers ignoring them. These include: how to use BDD to work with requirements, using a scientific method to fix problems in production (as opposed to shotgun debugging), verifying observability during development (before going to production), making the most interesting parts visible via higher order functions, and more. Nothing groundbreaking, but perhaps those will also work in your context.

Hypergrowth scaling made simple

This presentation will present a counterintuitive, straightforward, and business-friendly approach to creating a hyper-scalable systems using surprisingly simple architecture and patterns.

In the presentation, I will discuss how extraordinary simplicity can boost your growth with examples of Revolut's architecture, its advantages, and potential challenges. We will look into what does it mean that a system is complicated, complex, and how to make good architectural decisions to enable fast growth at the hypergrowth stage.

A promise: You will never look at systems of this scale the same way again.

Rewolucja w cyfrowych tożsamościach za sprawą Web3 i Self-Sovereign Identity

Obecnie w kontekście zarządzania naszymi cyfrowymi tożsamościami królują Facebook i Google z swoimi wtyczkami "Zaloguj z...". Takie podejście do zarządzania danymi osobowymi niesie sporo niebezpieczeństw, a nade wszystko oddala użytkownika od jego własnych cyfrowych tożsamości.

Self-Sovereign Identity (SSI) to ruch mający na celu oddać użytkownikowi kontrolę nad własną cyfrową tożsamością oraz tym, komu i jakie dane przekazuje. Pod parasolem SSI, poza ruchem społecznym, kryje się także stos technologiczny implementujący zdecentralizowanych model zarządzania tożsamościami.

Podczas prezentacji porównamy modele zarządzania tożsamościami, czym różni się SSI od już istniejących rozwiązań i - co najistotniejsze - o szczegółach samego SSI. Pomówimy o DID, Verifiable Credentials, Governance Frameworks i co w tym wszystkim robi blockchain.

Dla kogo my to robimy?

Nasza praca to robienie oprogramowania. W pędzie codziennych zadań często myślimy o kolejnych wymaganiach do zaimplementowania, kolejnych pull requestach do wystawienia, o jakości kodu i o tym, żeby wyrobić się w czasie. Czy pamiętamy wtedy o użytkownikach końcowych? Kim są? W jakim wieku są? Skąd pochodzą? Czy mają jakieś specjalne potrzeby? I dlaczego warto rozważać te pytania? Spotkajmy się i porozmawiajmy. Na prezentacji poznacie Darka, personę, która w swojej ewolucji będzie reprezentować wielu z nas.

Dlaczego buzzwordy szczęścia nie dają

Z jednej strony mówmy wszystko jako kod, z drugiej czasem do szczęścia brakuje nam dwóch kliknięć i gotowe, a kod zajmie nam godziny.
Z jednej strony mówimy HA, redundancja czy mikro-serwisy, a z drugiej nasza aplikacja ma load 300RPH (Request Per Hour w przeciwieństwie do Request Per Second) i przynosi niezłe pieniądze
Z jednej strony walczymy jak lwy w dyskusjach o SOLID, DRY czy YAGNI, a z drugiej siedzimy jak myszki pod miotłą, gdy ktoś porusza temat RODO/GDPR, ochrony danych czy przesyłania danych przez SFTP w plikach CSV.
Z jednej strony budujemy pipeline, które budują docker i wdrażają je na Kubernetes z użyciem Terraform i sprawdzają wszystkie podatności CVE, a z drugiej wypuszczamy naszą aplikację raz na 6 miesięcy i wszędzie musimy robić upgrade.
Z jednej strony na prezentacjach padają te wszystkie buzzword, a z drugiej człowiek wraca do biura i ....
No właśnie "co", o tych 3 kropkach będzie ta prezentacja. Z przykładami z życia, podejściem "na chłopski rozum" i w formie lekkiej dyskusji z Tobą słuchaczu.

Microservices, Data, Decoupling and Messages

Co nas czeka, gdy już zrealizujemy naszą nową doskonałą architekturę mikroserwisową? Jakie nieoczekiwane problemy odkryjemy, gdy nasz kod trafi na produkcję?

Rok temu mieliśmy we FLYR monolityczny backend RESTowej aplikacji i powstające wokół niego nowe serwisy. Wiedzieliśmy, że część funkcjonalności tego monolitu będzie potrzebna w nowych produktach tworzonych przez nowe zespoły. Poświęciliśmy sporo czasu i uwagi, żeby nauczyć się jak zaprojektować łatwą w utrzymaniu, skalowalną i luźno powiązaną architekturę mikroserwisów do przetwarzania opartego na danych. Teraz, gdy część pracy jest za nami i działa na produkcji, chciałem Wam opowiedzieć nie tylko, jak to zaprojektowaliśmy, ale przede wszystkim czego się nauczyliśmy już po pierwszych produkcyjnych wdrożeniach.

Chciałbym, żebyście z tej prezentacji dowiedzieli się przede wszystkim, jakie pułapki czekają po wdrożeniu mikroserwisów i na jakie szczegóły warto zwrócić uwagę – problemy, o których często nie mówi się na prezentacjach, bo rzekomo "to oczywiste" i "wszyscy to wiedzą". Ale czy rzeczywiście?

GitHub Action i GitHub Copilot w pracy DevOps’a

Zadania DevOps’a skupiają się m.in. na pracy z infrastrukturą oraz kodem. Coraz częściej jednak stajemy przed zadaniem automatyzacji wytwarzania oprogramowania czy infrastruktury. Prezentacja skupi się na dwóch narzędziach wspomagających te działania.

W trakcie prezentacji przygotuję workflow w oparciu o GitHub Action wraz z integracją z chmurą Azure i wdrożeniem aplikacji. Przejdziemy przez przykłady automatyzacji pisania kodu infrastruktury wykorzystując GitHub Copilot.

Autostopem przez JavaScript - Poradnik dla Backendowców

W świecie backendu dość łatwo przychodzi znajomość wielu języków. Paradygmaty się powtarzają, konwencje są podobne, a języki czerpią pomysły od siebie nawzajem. Doświadczeni takim stanem rzeczy, backendowcy coraz chętniej sięgają w stronę full-stacku, po JavaScript. Przecież z roku na rok JavaScript wygląda coraz bardziej znajomo - ma już klasy i w ogóle!

Nie trzeba jednak bardzo się starać, żeby natknąć się na jeden z wielu przypadków, w których JavaScript zachowa się zupełnie inaczej niż byśmy się tego spodziewali. Co? Dlaczego? Kto to wymyślił?! - Na te I inne pytania odpowiedź znajdziemy po drodze do nowej intuicji w tym jakże odmiennym świecie JavaScriptu.

Syndrom Oszusta w IT

Czy dopada Cię czasami to okropne uczucie, że nie jesteś wystarczająco dobry, żeby robić swoją robotę? Że brak Ci umiejętności, inteligencji i talentu? Że wszyscy wokół Ciebie wiedzą, co robią, a Ty prześlizgujesz się wyłącznie dzięki szczęściu, przypadkowi i sprawianiu wrażenia, że jesteś lepszy, niż w rzeczywistości? Czy żyjesz w strachu, że to jedynie kwestia czasu, aż ktoś wreszcie odkryje, że jesteś zwyczajnym oszustem?

Nie jesteś sam.

Według badań, Syndrom Oszusta dotyka niemal 90% osób pracujących w IT. W tej prezentacji opowiem czym ów syndrom jest, czemu jest tak dominujący w naszej branży, jak wpada się w błędne koło i dokąd można się stoczyć. Omówię, jak znajomość prostych mechanizmów pomoże Ci dostrzec swoje kompetencje oraz jakie triki stosować, żeby nie dać się pokonać demonom niepewności.

*Może zawierać śladowe ilości gumowych kaczuszek.

7 grzechów głównych tech leada

Zostałeś tech leadem i co dalej?

W idealnym świcie przejmujesz idealnie zgrany, autonomiczny zespół, który pracuje nad projektem bez grama legacy. Co miesiąc żonglujecie nowymi technologiami, a jedyną sytuacją kryzysową jest brak kawy w biurowej kuchni.

Rzeczywistość wygląda zupełnie inaczej. Zróżnicowany, niezgrany zespół, niskie morale, a może projekt, który jest legacy od momentu pierwszego commita? Czasami to dowolna konfiguracja tych problemów, a czasami wszystkie na raz.

Podczas prezentacji spróbujemy odpowiedzieć sobie na pytania jak prowadzić zespół tak, aby nie zwariować oraz po co i czy, w ogóle, warto zostać tech leadem.

Teściowa potrzebowała Toyotę Yaris więc kupiliśmy jej BMW X6

Praca nad systemem dla nowego klienta to zawsze wyzwanie. Nowe środowisko, inny zakres kompetencji, odmienne oczekiwania. Doradzamy, rozmawiamy, zastanawiamy się – krok po kroku tworzymy nowe usługi oraz komponenty. Mijają tygodnie, potem miesiące, a my coraz bardziej naginamy rzeczywistość, aby zmieścić się w wycenach, estymacjach, celach. W końcu nadchodzi upragniony koniec, idziemy na produkcję i patrzymy z boku na nasze dzieło. Sukces! Skończyliśmy z małym potworkiem, do którego ciężko się przyznać, ale na szczęście mamy kolejny projekt na horyzoncie. Pyk, nowa pozycja w CV a nasza abominacją na całe szczęście zajmie się kto inny.

W trakcie prezentacji porozmawiamy o tym jak bardzo nasze ego przeszkadza w delivery, o czym zapominamy podczas analizy potrzeb klienta i dlaczego musieliśmy przebudować garaż tytułowej teściowej.

Rola QA w starciu z nadciągającym AI - Czy to koniec testów jakie znamy?

Temat sztucznej inteligencji coraz odważniej wkracza w przestrzeń wytwarzania oprogramowania. Obietnice, jakie składa AI, zawładnęły głowami zarządów wielu firm w naszej branży, co jest wyraźnie widoczne na dzisiejszych rynkach pracy. Artykuły i eksperci opowiadają o korzyściach wynikających z testów z wiodącym udziałem AI, ale czy nie są one składane tylko na kredyt? Czy to koniec testów manualnych, a testerzy staną się zbędni? Czy automatyzacja testów w projektach stanie się standardem? Czy może to tylko kolejne zamieszanie, które dostarczy jeszcze więcej oprogramowania do testów?

Modularyzacja - miało być tak pięknie a wyszło jak zwykle

Przepiszmy to! - to hasło padło w niejednym projekcie. Zaciągany latami dług technologiczny i złe decyzje nawarstwiały się, utrudniając coraz to bardziej efektywne rozwijanie projektu i dostarczanie nowych funkcji. Niestety po przepisaniu sporej części systemu często okazuje się, że choć kod jest nowszy, to pierwotne problemy cały czas istnieją dalej... Skuteczna refaktoryzacja to piramida działań na wielu poziomach. W designie kodu, architekturze, rozmowie, organizacji. Jeśli problem jest na wyższej warstwie, na niższej często maskujemy jego skutki. Weźmy więc pod lupę piramidę refaktoryzacji i na bazie realnych doświadczeń z projektów zobaczmy, w jaki sposób i jakimi narzędziami można naprawiać projekt na poszczególnych poziomach.

25 lat mijania się z prawdą

Kto nie chciałby zobaczyć, jak tym wystąpieniem niszczę swoją karierę? Minęło 25 lat, co brzmi jak wyrok za ciężką zbrodnię z mrocznych zakątków kodeksu karnego, ale dla mnie to czas podsumowań. Prezentacja, stand-up, coaching? - nazwijcie to jak chcecie. Będzie o naszej branży, biznesie i o nas samych, o "uniwersalnych kłamstwach", które często powtarzane stają się prawdą. To będzie brutalny przewodnik po karierze w IT. Wielu z was zapewne poczuje się urażonych, ale jestem gotów na to poświęcenie. Czy wybór technologii ma znaczenie? Dlaczego większość stanowisk to "bullshit jobs"? Czy greenfieldy naprawdę są takie fajne? Komu potrzebne są estymaty? Co się dzieje, kiedy nie udaje się dowieźć sprintu? Jak feedback stał się rakiem toczącym organizacje? Dlaczego duża część z nas ma wrażenie, że ciągle robi to samo? I jak w tym bajzlu zachować szacunek do siebie, zdrowie psychiczne i dobrze bawić się przez 25 lat? Postaram się odpowiedzieć na te i inne pytania, które sam sobie stawiam od dłuższego czasu. Ci którzy odsieją śmiech przez łzy w tej prezentacji, odnajdą kilka cennych rad jak pokierować swoją karierą.

Wolni jak ślimaki, pasywni jak rurkowce

Jest rok 2023. Postęp technologiczny, który widzimy robi wrażenie. Mimo to pytanie, które w kuluarach zadaje sobie wiele (większość?) firm wytwarzających oprogramowanie brzmi “Co zrobić by software development był u nas szybszy? Okazuje się, że jako ruch Software Craftsmanship mamy odpowiedź na to pytanie.

W trakcie prezentacji spojrzę na temat szybkości wytwarzania oprogramowania – problemy, przyczyny i rozwiązania z różnych perspektyw. Pokażę kto znajduje się w centrum tego zagadnienia i jak może sprawić by było lepiej 😉

Modularyzacja - miało być tak pięknie a wyszło jak zwykle

Przepiszmy to! - to hasło padło w niejednym projekcie. Zaciągany latami dług technologiczny i złe decyzje nawarstwiały się, utrudniając coraz to bardziej efektywne rozwijanie projektu i dostarczanie nowych funkcji. Niestety po przepisaniu sporej części systemu często okazuje się, że choć kod jest nowszy, to pierwotne problemy cały czas istnieją dalej... Skuteczna refaktoryzacja to piramida działań na wielu poziomach. W designie kodu, architekturze, rozmowie, organizacji. Jeśli problem jest na wyższej warstwie, na niższej często maskujemy jego skutki. Weźmy więc pod lupę piramidę refaktoryzacji i na bazie realnych doświadczeń z projektów zobaczmy, w jaki sposób i jakimi narzędziami można naprawiać projekt na poszczególnych poziomach.

Dyskrecja DevOpsa. Co robimy w ukryciu?

Bezpieczeństwo danych, wdrożenia na produkcję, milionowe biznesy i dostęp tylko w razie potrzeby. Wszystkie aspekty automatyzacji budowania i wdrażania aplikacji w zabezpieczonym środowisku składają się na obraz zadania, które jednocześnie ma dobrze znane prawidłowe rozwiązania i bardzo łatwo zrealizować je źle. A ponieważ konsekwencje zaniedbań mogą spowodować nagłe zmiany w karierze, to warto o nich pomyśleć wcześniej. Zróbmy to teraz.

Beyond Clean Code: Ethernal architectural practises

In this talk we will cover: thinking in terms of abstractions, placing the right language in the right places, fighting with cognitive load and biases, what kinds of coupling can we see and which one is the worst, how to overcome the fear of having many small classes, hot to explain cohesion to a junior developer and more. Those evergreen rules can help you become more efficient and persuasive at work.

Best practices in practice: things that work for me so well I cannot believe you are not using them

There’s a lot of “best practices” around, but after 20 years of work I’ve found a set that really helps get my systems done well. I’d like to share those tools and methods and why they work in my context. While they are not a novelty (some of them have years of history), I see even experienced developers ignoring them. These include: how to use BDD to work with requirements, using a scientific method to fix problems in production (as opposed to shotgun debugging), verifying observability during development (before going to production), making the most interesting parts visible via higher order functions, and more. Nothing groundbreaking, but perhaps those will also work in your context.

Rewolucja w cyfrowych tożsamościach za sprawą Web3 i Self-Sovereign Identity

Obecnie w kontekście zarządzania naszymi cyfrowymi tożsamościami królują Facebook i Google z swoimi wtyczkami "Zaloguj z...". Takie podejście do zarządzania danymi osobowymi niesie sporo niebezpieczeństw, a nade wszystko oddala użytkownika od jego własnych cyfrowych tożsamości.

Self-Sovereign Identity (SSI) to ruch mający na celu oddać użytkownikowi kontrolę nad własną cyfrową tożsamością oraz tym, komu i jakie dane przekazuje. Pod parasolem SSI, poza ruchem społecznym, kryje się także stos technologiczny implementujący zdecentralizowanych model zarządzania tożsamościami.

Podczas prezentacji porównamy modele zarządzania tożsamościami, czym różni się SSI od już istniejących rozwiązań i - co najistotniejsze - o szczegółach samego SSI. Pomówimy o DID, Verifiable Credentials, Governance Frameworks i co w tym wszystkim robi blockchain.

Dla kogo my to robimy?

Nasza praca to robienie oprogramowania. W pędzie codziennych zadań często myślimy o kolejnych wymaganiach do zaimplementowania, kolejnych pull requestach do wystawienia, o jakości kodu i o tym, żeby wyrobić się w czasie. Czy pamiętamy wtedy o użytkownikach końcowych? Kim są? W jakim wieku są? Skąd pochodzą? Czy mają jakieś specjalne potrzeby? I dlaczego warto rozważać te pytania? Spotkajmy się i porozmawiajmy. Na prezentacji poznacie Darka, personę, która w swojej ewolucji będzie reprezentować wielu z nas.

Dlaczego buzzwordy szczęścia nie dają

Z jednej strony mówmy wszystko jako kod, z drugiej czasem do szczęścia brakuje nam dwóch kliknięć i gotowe, a kod zajmie nam godziny.
Z jednej strony mówimy HA, redundancja czy mikro-serwisy, a z drugiej nasza aplikacja ma load 300RPH (Request Per Hour w przeciwieństwie do Request Per Second) i przynosi niezłe pieniądze
Z jednej strony walczymy jak lwy w dyskusjach o SOLID, DRY czy YAGNI, a z drugiej siedzimy jak myszki pod miotłą, gdy ktoś porusza temat RODO/GDPR, ochrony danych czy przesyłania danych przez SFTP w plikach CSV.
Z jednej strony budujemy pipeline, które budują docker i wdrażają je na Kubernetes z użyciem Terraform i sprawdzają wszystkie podatności CVE, a z drugiej wypuszczamy naszą aplikację raz na 6 miesięcy i wszędzie musimy robić upgrade.
Z jednej strony na prezentacjach padają te wszystkie buzzword, a z drugiej człowiek wraca do biura i ....
No właśnie "co", o tych 3 kropkach będzie ta prezentacja. Z przykładami z życia, podejściem "na chłopski rozum" i w formie lekkiej dyskusji z Tobą słuchaczu.

GitHub Action i GitHub Copilot w pracy DevOps’a

Zadania DevOps’a skupiają się m.in. na pracy z infrastrukturą oraz kodem. Coraz częściej jednak stajemy przed zadaniem automatyzacji wytwarzania oprogramowania czy infrastruktury. Prezentacja skupi się na dwóch narzędziach wspomagających te działania.

W trakcie prezentacji przygotuję workflow w oparciu o GitHub Action wraz z integracją z chmurą Azure i wdrożeniem aplikacji. Przejdziemy przez przykłady automatyzacji pisania kodu infrastruktury wykorzystując GitHub Copilot.

Autostopem przez JavaScript - Poradnik dla Backendowców

W świecie backendu dość łatwo przychodzi znajomość wielu języków. Paradygmaty się powtarzają, konwencje są podobne, a języki czerpią pomysły od siebie nawzajem. Doświadczeni takim stanem rzeczy, backendowcy coraz chętniej sięgają w stronę full-stacku, po JavaScript. Przecież z roku na rok JavaScript wygląda coraz bardziej znajomo - ma już klasy i w ogóle!

Nie trzeba jednak bardzo się starać, żeby natknąć się na jeden z wielu przypadków, w których JavaScript zachowa się zupełnie inaczej niż byśmy się tego spodziewali. Co? Dlaczego? Kto to wymyślił?! - Na te I inne pytania odpowiedź znajdziemy po drodze do nowej intuicji w tym jakże odmiennym świecie JavaScriptu.

Syndrom Oszusta w IT

Czy dopada Cię czasami to okropne uczucie, że nie jesteś wystarczająco dobry, żeby robić swoją robotę? Że brak Ci umiejętności, inteligencji i talentu? Że wszyscy wokół Ciebie wiedzą, co robią, a Ty prześlizgujesz się wyłącznie dzięki szczęściu, przypadkowi i sprawianiu wrażenia, że jesteś lepszy, niż w rzeczywistości? Czy żyjesz w strachu, że to jedynie kwestia czasu, aż ktoś wreszcie odkryje, że jesteś zwyczajnym oszustem?

Nie jesteś sam.

Według badań, Syndrom Oszusta dotyka niemal 90% osób pracujących w IT. W tej prezentacji opowiem czym ów syndrom jest, czemu jest tak dominujący w naszej branży, jak wpada się w błędne koło i dokąd można się stoczyć. Omówię, jak znajomość prostych mechanizmów pomoże Ci dostrzec swoje kompetencje oraz jakie triki stosować, żeby nie dać się pokonać demonom niepewności.

*Może zawierać śladowe ilości gumowych kaczuszek.

7 grzechów głównych tech leada

Zostałeś tech leadem i co dalej?

W idealnym świcie przejmujesz idealnie zgrany, autonomiczny zespół, który pracuje nad projektem bez grama legacy. Co miesiąc żonglujecie nowymi technologiami, a jedyną sytuacją kryzysową jest brak kawy w biurowej kuchni.

Rzeczywistość wygląda zupełnie inaczej. Zróżnicowany, niezgrany zespół, niskie morale, a może projekt, który jest legacy od momentu pierwszego commita? Czasami to dowolna konfiguracja tych problemów, a czasami wszystkie na raz.

Podczas prezentacji spróbujemy odpowiedzieć sobie na pytania jak prowadzić zespół tak, aby nie zwariować oraz po co i czy, w ogóle, warto zostać tech leadem.

Teściowa potrzebowała Toyotę Yaris więc kupiliśmy jej BMW X6

Praca nad systemem dla nowego klienta to zawsze wyzwanie. Nowe środowisko, inny zakres kompetencji, odmienne oczekiwania. Doradzamy, rozmawiamy, zastanawiamy się – krok po kroku tworzymy nowe usługi oraz komponenty. Mijają tygodnie, potem miesiące, a my coraz bardziej naginamy rzeczywistość, aby zmieścić się w wycenach, estymacjach, celach. W końcu nadchodzi upragniony koniec, idziemy na produkcję i patrzymy z boku na nasze dzieło. Sukces! Skończyliśmy z małym potworkiem, do którego ciężko się przyznać, ale na szczęście mamy kolejny projekt na horyzoncie. Pyk, nowa pozycja w CV a nasza abominacją na całe szczęście zajmie się kto inny.

W trakcie prezentacji porozmawiamy o tym jak bardzo nasze ego przeszkadza w delivery, o czym zapominamy podczas analizy potrzeb klienta i dlaczego musieliśmy przebudować garaż tytułowej teściowej.

Rola QA w starciu z nadciągającym AI - Czy to koniec testów jakie znamy?

Temat sztucznej inteligencji coraz odważniej wkracza w przestrzeń wytwarzania oprogramowania. Obietnice, jakie składa AI, zawładnęły głowami zarządów wielu firm w naszej branży, co jest wyraźnie widoczne na dzisiejszych rynkach pracy. Artykuły i eksperci opowiadają o korzyściach wynikających z testów z wiodącym udziałem AI, ale czy nie są one składane tylko na kredyt? Czy to koniec testów manualnych, a testerzy staną się zbędni? Czy automatyzacja testów w projektach stanie się standardem? Czy może to tylko kolejne zamieszanie, które dostarczy jeszcze więcej oprogramowania do testów?

Microservices, Data, Decoupling and Messages

Co nas czeka, gdy już zrealizujemy naszą nową doskonałą architekturę mikroserwisową? Jakie nieoczekiwane problemy odkryjemy, gdy nasz kod trafi na produkcję?

Rok temu mieliśmy we FLYR monolityczny backend RESTowej aplikacji i powstające wokół niego nowe serwisy. Wiedzieliśmy, że część funkcjonalności tego monolitu będzie potrzebna w nowych produktach tworzonych przez nowe zespoły. Poświęciliśmy sporo czasu i uwagi, żeby nauczyć się jak zaprojektować łatwą w utrzymaniu, skalowalną i luźno powiązaną architekturę mikroserwisów do przetwarzania opartego na danych. Teraz, gdy część pracy jest za nami i działa na produkcji, chciałem Wam opowiedzieć nie tylko, jak to zaprojektowaliśmy, ale przede wszystkim czego się nauczyliśmy już po pierwszych produkcyjnych wdrożeniach.

Chciałbym, żebyście z tej prezentacji dowiedzieli się przede wszystkim, jakie pułapki czekają po wdrożeniu mikroserwisów i na jakie szczegóły warto zwrócić uwagę – problemy, o których często nie mówi się na prezentacjach, bo rzekomo "to oczywiste" i "wszyscy to wiedzą". Ale czy rzeczywiście?

Hypergrowth scaling made simple

This presentation will present a counterintuitive, straightforward, and business-friendly approach to creating a hyper-scalable systems using surprisingly simple architecture and patterns.

In the presentation, I will discuss how extraordinary simplicity can boost your growth with examples of Revolut's architecture, its advantages, and potential challenges. We will look into what does it mean that a system is complicated, complex, and how to make good architectural decisions to enable fast growth at the hypergrowth stage.

A promise: You will never look at systems of this scale the same way again.

(Nie)trudna sztuka modelowania agregatów

Agregaty to chyba natrudniejszy element konstrukcyjny taktycznego Domain-Driven Design. Czy naprawdę chodzi tylko (lub aż) o dobrze skrojone programowanie obiektowe?

Dobrze zaprojektowany agregat potrafi wyeliminować potrzebę dokupowania chmury dla naszych czterdziestu mikroserwisów. Źle zaprojektowany agregat potrafi sprawić, że używanie systemu jest koszmarem.

W tym praktycznym warsztacie przejdziemy przez typowe przypadki modelowania i implementacji agregatów. Tak, typowe, bo... nasze projekty mocno się nie różnią. Zahaczymy też o archetypy.

Wymagania

• Laptop
• GIT
• Większość warsztatu odbędzie się na platformie miro.com, więc dobrze się z nią zapoznać (zajmuje sie jakieś 2 minuty)
• Dodatkowo warto mieć zainstalowane ulubione IDE, ulubiony język oraz klienta git (bo może pojawi się nasz wspólny kod)
• będziemy pracować w grupach (2-4 osobowych, w zależności od liczby osób)

Wydajność aplikacji Java dla ciekawskich

Celem tego warsztatu jest łagodne wprowadzenie Cię w świat wydajności na platformie JVM. Nie wiesz nic o JMH, JFR, async profiler, dlaczego twój kod musi być wygrzewany? Nigdy nie widziałeś "flamegraph"?

Spokojnie. Tego wszystkiego dowiesz się podczas jednodniowego warsztatu. Skupimy się nie tylko na narzędziach, ale także na procesie i technikach optymalizowania wydajności. Weźmiemy na warsztat jeden z sztandarowych modeli przetwarzania danych, "map reduce". Od prostej jednowątkowej implementacji, po wielowątkowe monstrum oparte o fork-join pool, będziemy poznawać techniki i narzędzia pracy z testami wydajnościowymi ( w skali micro, znanymi także jako "microbenchmark").

Będzie też czas na zapoznanie się z mechanizmami JVM, takimi jak just-in-time compiler, garbage collector czy adaptive locking. Więcej informacji na stronie https://jvmperformance.pl/.

Wymagania

• JDK 20
• Docker
• Maven
• Zaznajomienie się z biznesowymi i technicznymi metodami modularyzacji systemu.
• IDE

Rejestracja uczestników

Rozpoczęcie konferencji

Przerwa obiadowa

Zakończenie konferencji

Przerwa kawowa

After Party

Stary Browar Rzeszowski, Rynek, tuż obok Bristolu.